• chore(engine): publish engine bases in ci #4649 : 3 dependent PRs (#4650 , #4652 , #4666 )
• chore: lockfile lefthook #4647
• fix(rivetkit): surface native sqlite kv errors to callers #4645
• fix(rivetkit): prevent sleep races during disconnect and db work #4644 👈 (View in Graphite)
• fix(rivetkit): isolate engine envoys and propagate startup failures #4643
• test(rivetkit): remove wasm sqlite-only fixtures and coverage #4642
• chore(sqlite-vfs): remove wasm sqlite packages and workspace wiring #4641
• chore(rivetkit): remove wasm sqlite runtime #4614
• fix(sqlite-native): restore native startup kv preload #4639
• fix(sqlite-native): delete metadata before chunk range #4638
• fix(sqlite-native): keep truncate cache coherent #4637
• fix(sqlite-vfs): use delete range for truncate cleanup #4636
• fix(sqlite-native): restore kv error hook #4635
• perf(sqlite-native): avoid cloning cached read chunks #4634
• perf(sqlite-native): gate kv operation labels #4633
• perf(sqlite-native): reuse read cache for partial writes #4632
• perf(sqlite-native): remove delete file existence probe #4631
• fix(sqlite-native): gate native read cache behind env var #4630
• fix(pegboard): isolate runner config dc lookup failures #4625 : 1 other dependent PR (#4626 )
• docs(pegboard): note runner config upsert split write risk #4624
• fix(pegboard): unpack global runner config keys correctly #4623
• fix(pegboard-gateway): enforce tunnel message state #4622
• fix(pegboard-runner): clear terminal tunnel routes #4621
• fix(pegboard): skip protocol version keys in runner pool backfill #4620
• fix(pegboard): create missing normal runner configs #4619
• fix(epoxy): reuse cached optimistic value #4618
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Code Review

Overview

This PR fixes a race condition in the actor sleep lifecycle where an actor could enter sleep prematurely when a connection is being disconnected but the onDisconnect callback has not yet completed.

Two targeted changes:

1. connection-manager.ts: Calls resetSleepTimer() immediately after pendingDisconnectCount increments, so the timer is re-evaluated with the pending disconnect work counted.
2. mod.ts: Adds a safety guard inside the setTimeout callback. If canSleep() is no longer Yes when the timer fires, it re-arms the timer instead of proceeding to sleep.

Race Condition Being Fixed

Before this fix:

1. Last connection removed from connections so canSleep() returns CanSleep.Yes
2. resetSleepTimer() is called from an earlier call site and sets a sleep timer
3. pendingDisconnectCount increments but the timer is already armed
4. Timer fires and startSleep() is called while onDisconnect callback is still running

The fix ensures that after incrementing pendingDisconnectCount, the timer is immediately reset so the next canSleep() evaluation returns CanSleep.ActiveDisconnectCallbacks.

The guard in the setTimeout callback provides defense-in-depth for any remaining timing gaps.

Code Quality

Strengths:

• Minimal diff (5 lines added) -- touches only what needs changing.
• Fix is placed directly after the state mutation it guards against.
• The double resetSleepTimer() call in connDisconnected (once after increment, once in finally after decrement) is intentional and correct.
• The timer callback guard is consistent with how resetSleepTimer() already re-evaluates state.

Suggestions:

1. Add a comment to the timer guard. The re-check inside the setTimeout callback is non-obvious. A brief inline comment explaining why canSleep() needs to be re-evaluated at fire time (state may have changed since the timer was armed) would help future readers.

2. Fill out the PR description. The checklist and test/motivation fields are empty. Even a single sentence describing the race would be valuable for git history.

3. Regression test (optional). The existing sleep tests do not cover this specific race. A test that closes a connection and asserts the actor does not enter sleep before onDisconnect completes would prevent future regressions, though the timing-dependent nature makes this hard to write reliably.

Verdict

The logic is correct and the fix is well-targeted. No functional concerns. The main suggestion is a short comment on the timer guard in mod.ts to document the intent.